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We describe the security verification of OpenTitan. We illustrate how information flow tracking 
turns human knowledge of assets and security requirements into formal security properties verified 
using Cycuity’s Radix. The verification uncovered weaknesses and helped produce hardware fixes to 


eliminate vulnerabilities. 


O penTitan is a commercial-grade, open-source 
hardware root of trust (RoT). RoTs perform 


security-critical functionalities such a 
the configurat ration modes (eg, re ver- 
sus BeeT or managemen of sensitive data (e.g., 


cryptographic keys). OpenTitan i is main 


enterprises, platform providers, and chip manufacturers 


as a platform integrity module, universal second-factor 
security key, and trusted platform module. The Open Ti- 
tan includes a security-enhanced RV32IMCB RISC-V 
Ibex core, various security peripherals (e.g., Advanced 
Encryption Standard, Keccak Message Authen- 
tication Code, Hash-based Message Authentication 
Code), multiple memories [e.g., ROM, FLASH, static 
random-access memory (SRAM), one-time program- 
mable (OTP) ] with dedicated controllers for access 
control and scrambling purposes, and different input- 
output peripherals. 
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OpenTitan has well-documented security require- 
ments and verification procedures. The OpenTitan 
threat model describes the security assets, poten- 
tial attacker profiles, attack surfaces, and methods. 
The threat model is used to derive relevant security 
requirements. OpenTitan defines a security model 
specification that includes device provisioning and 
run-time operations, secure hardware design guide- 
lines, and functional guarantees. OpenTitan includes 
testing plans, testbench architecture, a security coun- 
termeasure verification framework, design guides, and 
integrates with formal and simulation-based verifica- 
tion tools. 

This article sas pou the sec 
process for the O n O' , 
holds secret data aed for secure boot, lifecycle provi- 
sioning, and attestation. Thus, it plays a key role in the 
overall security of OpenTitan. We describe an impor- 
tant security asset, derive requirements for that asset 
and the OTP operation, and write formal properties 
that specify the requirements. The goal is to give the 
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reader an understanding of the state of the art in silicon 
security verification. 


Our security verification process uses information © 


-flow tracking (IFT) to perform hardware security | 
verification. Using IFT, we find a potential hardware 
weakness, localize the weakness, propose a hardware 
patch, and verify the patch is secure. IFT enables veri- 
fication engineers to reason about 


expressed agikHEENENESy- "nauneanenlietihaay 
vide a more concise and expressive representation 
1S 


eof integri aby ch 


2 Commer- 


cial hardware IFT techniques have emerged as a criti- 
cal tool for hardware security. 


We use Geinor 
Gumi. Raiz is an IF T-enhance 


simulation tool that allows designers to express and 
verify security properties easily. The verification engi- 


neer must identify critical design assets and formalize 
the security requirements for those design assets using 
security properties. Those properties are provided to 
IFT security verification tools, which uncover secu- 
rity property violations. We describe how to assess the 
severity of these weaknesses and determine how to 
repair the security weakness to eliminate unnecessary 
confidential information leakage. This hardware patch 
was integrated into the OpenTitan design. 

The contributions of the article include the following: 


« describing the state of the art in hardware security 
verification using open-source OpenTitan hardware 
root of trust 


demonstrating the value and effectiveness of hardware 
IFT as a verification approach to formalize the secu- 
rity property, identify a potential weakness, debug the 
root cause, and repair the flaw 


uncovering a weakness in the OpenTitan OTP mem- 
ory controller, providing a patch to fix the OpenTitan, 
and submitting a common weakness enumeration 
(CWE) around the weakness. 


OpenTitan OTP Memory Controller 
The OTP memory controller is a peri 
interconnect bus which manages the OpenTitan’s OTP 


memory. “he O Geitasmnemaaiiesntimemaitin 
and includes information critical to secure system oper- 


ation like devi i i i 
s. The 1. Create the threat model. — 


controller provides access control to the OTP memory. 
consistency checks. The OTP controller is crucial for 


the correct and secure operation of OpenTitan. 
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Figure 1 describes the OTP controller architecture. 
It contains eight OTP partitions (PQ - P7) that hold data 
from the OTP memory. Partitions PO, Pl, and P2 are 
unbuffered, i.e, they do not store data; data are retrieved _ 
from the OTP memory on every access request. Parti- 
tions P3-P7 are buffered. The data in the buffered par- 
titions are retrieved upon boot from the OTP memory 
and stored locally in the OTP controller after that. 


Each of these partitions contains unique data with 


different access control requirements. The data in 


partitions P4, PS, P6 are SECRET. SECRET data are 


S 


Data can be read and write locked from software access 
statically or at run-time. Locked data are stored with 
a digest for integrity checks. Buffered data are stored 
with error correction control protection also used for 


integrity checks. 
The OTP scrambling datapath performs light- 
weight scrambling operations as requested by the 


partitions and its different interfaces. The OTP scram- 


block cipher. Secret data stored in the OTP memory 
are scrambled to protect against physical attack 
global netlist constant is used as the key, which is 
hardware design time (premanufacturing). The scram- 


The interfaces manage the interactions between 
OTP memory, the buffers, and other OpenTitan hard- 


ware modules. The register interface enables soft- 


Security Verification 


Hardware security verification can be broken down into 


six steps.“ 


2. Identify the assets. 

3. Determine securi for the assets. 

4. Define the ae N on Steps 1, 2, 
and 3. 

5. Specify security properties. — 

6. Verify the security properties. 
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The first five steps of this process are still largely 
manual. They rely heavily on verification engineers to 
describe the threat model, explicitly define the assets, 
develop the weakness and requirements, and finally 
specify the properties. i i 


Verification engineers often iterate these steps to 
refine the properties to more precisely define the secu- 
rity properties and provide adequate security coverage. 


verify the con- 


Now we use this six-step process to 


a discussed how hardware IFT 
verification is cr to assess potential security vul- 
nerabilities. Our analysis uncovered a weakness in the 
OTP memory controller. We describe how to assess the 
severity of the weaknesses and determine an appropri- 


ate hardware patch. This patch was integrated into the 
OpenTitan design. 


Step 1: Create the Threat Model 
The OTP controller specification states that its 
primary purpose is to provide “high-level logical 


fi e ke ef e security protection, such as integrity checks and 
~- otp_ast_ | otp_ctr1 
ipwr_seq_o / 
:  otp_ast_ 
pwr_seq_h_i Test Access Gate 
wa 
Bo] 
; TA heer: > OTP Wrapper 
Direct Access Interface E 3 (OTP Memory) 
(DAI) = 
ct 
oO 
D 
IRQs & 
Alerts P@: VENDOR_TEST 
(Unbuffered) 
2 Scrambling Datapath (OTP Scrambler) 
P1: CREATOR_SW_CFG 
(Unbuffered) 
v Scrambling Control 
a Es) 
g D 
S P2: OWNER_SW_CFG > 
2 (Unbuffered) o e 
= Loe PRESENT Encrypt 
TL-UL = © 
w 1 
Bus IF p 
: Ea pee. 
'*data_o*: 
tl i/o g 7 Mveady: o" PRESENT Decrypt 
= LFSR Timer, Alert & Error Ctrl 
(check intervals) 
-m 
B Life Cycle Interface 
i (LCI) 
— 
Key Derivation Interface 
(KDI) 


Hardware | Life-Cycle 
Broadcast j State & 
1 Tokens 


*otp_1c_data_o*; 


Figure 1. Block diagram of the OpenTitan’s OTP Memory Controller. The OTP controller provides access control to different interfaces. 
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Data can be marked as secret (stored encrypted), locked, and integrity checked. The scrambling datapath provides lightweight encryption 
operations to assist in different aspects of the access control. LFSR: linear feedback shift register. 
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scrambling of sensitive content.’ koe 


from readout, fault injection, and probing. Open- 


Titan encrypts secret data using a netlist constant 


Step 2: Identify Assets 

RndCnstKey is the security asset under verifica- 
tion. RndCnstKey is a global netlist constant in the 
OTP scrambler used as a key to protect secret data 


eee ee 


J J 
and register interface. Thus, there are many ways that 


RndCnstKey could inadvertently leak outside of the 
OTP controller. 


= 


PRESENT 


Figure 2. (a) A simplified block diagram of the PRESENT 
block cipher. (b) Waveform showing a single functional 
execution trace of the PRESENT block cipher module. (c) 
Waveform showing a single |FT-enhanced execution trace 
of the PRESENT block cipher module with red shading to 
indicate that a particular signal contains information (i.e. 
at least one of its security labels is HIGH) which originated 
from key. 
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Security Asset: RndCnstKey 


There are many other assets in the OpenTitan OTP 
controller. While we focus on security verification of 


key that is fixed in the hardware at design time. Our RndCnstKey, the general methodology applies to other 
Bi OA ae trees em Coane aie ee assets in the OpenTitan design. 


Step 3: Determine Security Weaknesses 


It is critical for RndCnstKey ae aoa ial; access 
to 


sitive data from the OTP memory: Any information related 


to the RndCnstKey should remain within the OTP control- 


stored in the OTP memory. Secret data includes the ler; no knowledge about RndCnstKey should leak outside 


the controller. Based on this, we can specify the security 
objective and security boundary for RndCnstKey. 


Security Objective: Confidentiality 


Security Boundary: All outputs of the OTP 
controller 


Step 4: Define Security Requirements 
Using the asset, objective, and boundary, we can specify 
the following plain-language security requirement: 


The “should not be visible” portion of the requirement 


comes about from the security objective of confidential- 
ity. Similarly, the “on the outputs of the OTP controller” 
comes from the security boundary. We want to verify that 
RndCnstKey data stays within the OTP controller. 


Step 5: Specify Security Properties 
Now, we convert our plain-language security require- 


ified security property. 


ment into a for 


Verification involves writing properties about behav- 
iors and using tools to assess if the hardware upholds 
those properties. Verification uses assertion languages 
to write statements about the behaviors. It allows the 
specification of temporal behaviors including event 


sequences, latencies, and pipelines. System Verilog Asser- 


Consider the PRESENT block cipher used in the 
OTP Scrambler. Figure 2 shows a simplified version 
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of PRESENT, which takes as input a key and data to 
scramble and outputs the scrambled data cipher. The 
ready signal indicates that the cipher data are valid. 
reset reinitializes the datapath. Figure 2(b) provides 
an example execution or trace. 


Functional verification properties are typi- 
cally expressed as ASE REELS 
behaviors over a single execution trace. Consider 
the trace property defined for the PRESENT block 
cipher module: 


(reset != 1) || (ready! = 1) 


The trace property specifies that if reset is 1 then 
ready is 0. The property can also be specified using the 
implication operator: |—> 


(reset == 1) |—> (ready != 1) 


A counterexample for a trace property can be des- 


cribed by a single trace of execution. Figure 2(b) pro- 
vides a counterexample trace wherereset == 1 at the 
same time thatready == 1. 


es are valuable for security verifica- 


tion, but they have li 
. For example, confiden- 


tiality properties state that no information about 
some data (e.g., RndCnstKey) can ever be leaked or 


inferred at another location. Or, more generally, infor- 
mation should not flow from a source to a destination. 
The dual of this is that the source data should never 
be able to affect the sink data, which expresses prop- 
erties related to data integrity. Confidentiality and 
integrity properties cannot be easily specified using a 
trace property. They require a more expressive prop- 
erty language. 

Hardware IFT is a security verification tech- 
nique that monitors how information from some 


‘of execution traces.” Hyperproperties are fundamen- 


tally more expressive than trace properties. 


from the key can never be inferred by observing the 
ready output signal. 


//1FT Property 


In other words, this IFT property states that no 
information from signal key should ever be deducible 


by viewing the signal ready. Any change in key should 
never affect the ready signal; they should operate inde- 


pendently. If there was a flow, then the attacker could 
l 


the PRESENT scrambler. 


e 

trace to describe an interfering behavior. A counterex- 
ample forkey =/=> ready hyperproperty requires at 
least two traces with differing values of key which show 
an effect on the ready value. 

The Cycuity Radix tools use IFT analysis for secu- 
rity verification. Radix takes as input IFT properties 
(also called Radix rules) that articulate behaviors related 
to the security requirements. These properties gener- 
ally take the form of: 


//Radix Security Rule/IFT Property 
{src_signal_set} =/=> {dest_signal_set} 


The property fails if any information from the src_ 
signal_set flows to the dest_signal_set. Vari- 
ous additional qualifiers exist, e.g., qualifiers to specify 
when the source data should be tracked and conditions 
under which data flows to the destination are allowable. 
Some of these qualifiers will become clearer when dem- 


source propagates throughout the hardware.° Hard- _ onstrated later on in this article. 


mation moves as the hardware executes. Hardware 
IFT enables designers to analyze the security of 
their design more efficiently. Verification engineers 
can learn where and how asset information travels 
throughout the hardware. 

The key aspect of IFT properties is specifying the 


notion of information flows (or lack thereof). We adopt 
the notation using used 
by Cycuity’s Radix software, to indicate noninterfer- 
ence between the source signal and the destination sig- 


nal. For example, we may want to assert that information 
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Radix translates the IFT property into an informa- 
tion flow security monitor using the design register 
transfer level code. Radix then tracks information flows 
over time allowing the verification engineer to uncover 
potential weakness, localize sources of the vulnerabil- 
ity, and develop hardware patches that eliminate the 
weakness. 

IFT-enhanced traces are more powerful than func- 
tional traces because they provide additional secu- 
rity properties to support noninterference using HIGH 
and LOW labels.° If a security label of a signal in an 
IFT-enhanced trace is HIGH, then it contains informa- 
tion from an asset defined in the src_signal_set 


signal, which would indicate 
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_ was marked as UOTE i.e., Da left-hand side of the no-flow operator (=/=> ). Simi- 
hose label is H contains informatio larly, we make the destination signals of the IFT prop- 


anced trace is suffi- erty all outputs of the OTP controller (specified using 
te ninterferen TEET Sempe Cycuity’s $all_outputs shorthand) based on the 

thar power and wale of bee IFT. requirement’s associated security boundary. This prop- 
Figure 2(c) depicts a single IFT-enhanced trace that erty will fail if any information from RndCnstKey flows 

provides a counterexample to thekey =/=> ready prop- to any of the outputs of the OTP controller. It should 

erty. The key always has a HIGH label (depicted with red be noted that this information is tracked through logi- 

shading) as this is the information that property expresses cal and sequential transformations and is independent 

to track. Later in the trace the ready and cipher signals ofthe value of RndCnstKey. 

are marked as HIGH, which indicates information about 

the key was transferred into those signals at that time, thus Step 6: Verify Security Properties 

providing a counterexample to the trace. Now that we have formally specified a security prop- 
Developing IFT properties is straightforward given erty, we can verify whether this proy holds for the 

a security requirement, objective, and boundary. The OTP controller. This verificat erformed via the 

following IFT property shows the IFT property for the i i i 

security requirement related to RndCnstKey: 


adix automatically generates the security monitor, 
which precisely tracks information flows in the Open- 


Titan design. The security property provides an ini- 
assert iflow( tial labeling of the RndCnstKey asset, i.e., setting its 
u_otp_ctrl_scrmbl .rnd_enst_key_anchor security label equal to HIGH. During simulation, Radix 


==> 


re reports if/when the associated security property is 


T violated by checking if the OTP output labels are set 
‘ as HIGH. 


Since the security objective for RndCnstKey’s require- 
ment is confidentiality, we make RndCnstKey the 
source signal for the IFT property by placing its corre- 
sponding design signal (rnd_cnst_key_anchor) o 
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reyes |Í KMAC EON [aoe] | LI pwm ore LY Mona } Key Manager ROM 
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ae | TE Entropy | (eee =| Padari Controller [P] — Control } ce 
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(IFT Properties) Monitor Generation 
Design Signals (Hierarchical Path) 623200000 626) 
assert iflow( u_otp_ctrl/u_otp_ctrl_scrmb1/\rnd_cnst_key_anchor[0]|| 74FC825441343DA92732261 : 
RndCnstKey : ; u_otp_ctr1/u_otp_ctrl_scrmbl/\rnd_cnst_key_anchor[1]|| 5703C3EB2B8563689£00867i : 
=/=> Radix u_otp_ctr1/u_otp_etrl_sermbl/\rnd_enst_key_anchor[2]]| 63E7BF615ABDA4C5EECB377° ; 
$a tl Guk We ` Runtime u_otp_ctrl/u_otp_ctrl_scrrbl/data_o| F964.. 3c46.. 
oa P Be s% ein u_otp_ctrl/u_otp_ctrl_scrmbl/ready_o}| : 
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Figure 3. An overview of the Radix workflow. Radix security rules are combined with the design RTL to create a set of information flow security 
monitors. These security monitors are then inserted into the existing semiconductor simulation (shown) or hardware emulation (not shown) 
environments for execution. 
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> more he erifyinga specified security property does not hold for OpenTi- 
r property than aler auc to hese key stimu- tans OTP controller. Figure 5 shows the hierarchical 
late the target ech - path through which this information leakage occurs. 


We found a violation of the security property. Now 
we must determine the extent of these weaknesses. 


IFT tools can help guide this debugging process. 


Figure 4 shows an IFT-enhanced trace where 
rnd_cnst_key_anchor is a source asset, i.e, those Analyzing a Falsified Security Property 


security labels are initialized as HIGH. We aim to There are generally t 


understand where the RndCnstKey information a property has been violated. The first approach 
flows. Any register with a HIGH label is shaded red. 


Indicated by the red shading o on otp_lc_data_o. 


test_unlock_token, i i 
/data_o. test_unlock_token which means that the 


: Design Signals (Hierarchical Path) 625600000ps 625700000ps 625800000ps 625900000ps 626000000ps 


u_otp_ctrl/u_otp_ctrl_scrmbl/\rnd_cnst_key_anchor[0] 
u_otp_ctrl/u_otp_ctrl_scrmbl/\rnd_cnst_key_anchor[1]|| 5703C3EB2B8563689800867814EFBDE8 
u_otp_ctrl/u_otp_ctrl_scrmbl/\rnd_cnst_key_anchor[2] [Seu E uy Sih cea nn | 
{@i0A.)(F6BDFS4iB.. F960.) 3c46..)6BFB.. 2533.) 


u_otp_ctrl/u_otp_ctrl_scrmbL/data_o 9E47.. (194B.. D280.. 7927..)2074.. F4AC.. 
u_otp_ctrl/u_otp_ctrl_scrmbl/ready_o 3 3 
u_otp_ctrl/otp_lc_data_o.test_unlock_token 3852305BAECF5FF1D5C1D25F6DB9058D 2.— F6BDF341BEA.. 


Figure 4. The first three waveforms (indicated in 1) correspond to RndCnstkKey. Red indicates that the register’s security label contains 
information from RndCnstkKey. Information related to RndCnstKey leaks to the output of the OTP controller (test _unlock_token) as 
indicated in 2. The number 3 shows unintended leakage of RndCnstKey via the OTP scrambler’s output data_o. 


_HP_C/\rnd_cnst_key_anchor[0] oe HP_D/wdata_i }————> HP_F/data_i] 
HP_C/\otp_enc_key_lut[0] HP_B/data_mux HP_D/ecc_enc *————_5 HP_F/data_o l 
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i D Cycles 
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2 HP_C/key_state_q HP_E/\gen_round[0].data_state_xor HP_D/data_o 

HP_C/enc_data_out HP_E/\gen_round[0].data_state_sbox 

HP_C/data_state_d HP_E/\data_state 

[HP _C/data_state q \cyctes” NHP_E/data_o 

: 30 Times ; 
HP_C/data_o ——————————————————> HP_ A/part_scrmbl_rsp_data HP_A/part_buf_data ——> HP_A/otp_lc_data_o.test_unlock_token l 
[HPA = /u_otp_ctrl/ HP_D/ = /u_otp_ctrl/u_P4/u_otp_ctrl_ecc_reg/ 

HP_B/ = /u_otp_ctrl/u_P4/ HP_E/ = /u_otp_ctrl/u_otp_ctrl_scrmbl/u_prim_present_enc/ : 
HP _C/ = /u_otp_ctrl/u_otp_ctrl_ scrmbl/ | HP_F/ = /u_otp_ctrl/u_P4/u_otp_ctrl_ecc_reg/u_prim_secded_inv_72_64 _enc/ |. 


Figure 5. The hierarchical path through which information related to RndCnstKey leaks to the output of the OTP controller (test_ 
unlock_token). Each node (i.e., colored rectangle) in the figure represents a design component (e.g., register, wire, and so on) in the OTP 
controller or one of its submodules. Each edge (i.e., arrow) indicates the flow of information from one design component to another. 
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secure. That is, due to the nature of the one-way encryp- 
tion function, no information about the key is inferable 
from the output, even though the output depends on 
the marked asset (the key). It is important to note that 


this property is only true when the module implement- 
eeen all a 


outputting intermediate cryptographic state/results 


during the encryption process invalidates the assump- 
tion that the key is protected by the one-way encryp- 
tion function. A refined version of the RndCnstKey 
property, which performs an explicit downgrade of 
information from the output of the PRESENT cipher, 
is as follows: 


assert iflow( 
u_otp_ctr1l_scrmb1 .rnd_cnst_key_anchor 


S 

$all_outputs 

ignoring 

u_otp_ctrl_scrmb1.data_o 

when (u_otp_ctrl_scrmbl.ready_o == 1) 
Me 


The base property remains the same—information 
from RndCnstKey should not flow to any of the out- 
puts of the OTP controller. However, we now have an 


whe i 
ready_o == 1. This is laces asa label downgrade or 


declassification.® 


the OTP controller. Since RndCnstKey encrypts data 


within the OTP controller and only fully encrypted 


Design Signals (Hierarchical Path) CHEE 


data are sent outside of the controller, the declassifica- 
tion of these flows using the ignoring clause is allow- 
able. We pass this updated security property to Radix-S 
and perform security verification. 

Figure 6 shows the simulation with this refined 
security property rnd_cnst_key_anchor. The differ- 
ence between this result and the previous one is that 
the information leakage from RndCnstKey to the out- 
put of the OTP controller (otp_lc_data_o.test_ 
unlock_token) no longer causes a property failure 
because it has been marked as an allowable flow. If this 
result still had the same property failure, that would 
indicate that the flow we saw in the initial result did 
not travel through data_o when ready_o was 1. How- 
ever, since the addition of the ignoring clause removed 
the property failure, we know that the flow we previ- 
ously saw was indeed due to the movement of the fully 
encrypted data. 


Fixing Intermediate Leakage of RnACnStKey 
Figures 4and 6 show that 


[sree «x ^01 the OTP scrambler exposes 
e input to the scrambler via data_o (see Figures 4 and 


625700000ps 


625800000ps 625900000ps 626000000ps 
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Figure 6. The first three waveforms (indicated in 1) correspond to RndCnstKey. Red indicates that the register’s security label contains 
information from RndCnstKey. Unlike the trace shown in Figure 4, information related to RndCnstKey does not leak to the output of the OTP 
controller (test_unlock_token) as indicated by the lack of red in 2. The number 3 shows unintended leakage of RndCnstKey via the OTP 


scrambler’s output data_o. 


34 IEEE Security & Privacy 


May/June 2023 


625600000ps 625700000ps 625800000ps 625900000ps 626000000ps 


l Design Signals (Hierarchical Path) [i 
u_otp_ctrl/u_otp_ctrl_scrmbl/\rnd_cnst_key_anchor[0] | 74FC825441343DA9273226119C9DD48B ) | 
. 5703C3EB2B8563689800867814EFBDE8 
u_otp_ctrl/u_otp_ctrl_scrmbl/\rnd_cnst_key_anchor[2] E P 


u_otp_ctrl/u_otp_ctrl_scrmbl/\rnd_cnst_key_anchor[1] 


© secret assets, The old code pem drives data_ 


u_otp_ctrl/u_otp_ctrl_scrmbl/data_o 


u_otp_ctrl/u_otp_ctrl_scrmbl/ready_o 


u_otp_ctrl/otp_lc_data_o.test_unlock_token 


3 


3852305BAECF5FF1D5C1D25F6DB9058D 2 


3 


| F6BDF341BEA.. 


OO F348... —| 


Figure 7. The first three waveforms correspond to RndCnstkKey. Red indicates that the register’s security label contains information from 


RndCnstKey. The number 3 shows that the unintended leakage of RndCnstKey has been fixed by our proposed solution. Instead of 


driving intermediate cryptographic state to the OTP scrambler’s output (data_o), our solution drives a safe default value which carries no 


information from RndCnstKey. 


//Old Code (Original Design) 
assign data_o = data_state_q; 


//New Code (Our Solution) 
assign data_o = (valid_q)? 
data_state_q: ð; 


W e demonstrate the value of simulation-based 
hardware IFT analysis for hardware secu- 
rity verification. IFT quickly moves knowledge about 
design assets to define security requirements, secu- 
rity objectives, and security boundaries. IFT enables 
concise specification of security properties related to 
confidentiality, integrity, and availability. IFT hard- 
ware verification tools like Cycuity Radix can help 
verify, refine, and extend security properties. We 
identified a weakness in the OpenTitan OTP mem- 


state_q is assigned the value of the input to the scram- ory controller, localized the source of the error, and 


bler (data_i ). Following this, data_state_q is assigned 


(there 


state_q to the output of the OTP scrambler (data_o), 
which leads to the intermediate state leakage outside of 
the OTP scrambler. To prevent this intermediate leak- 


age, our proposed solution only drives data_state_q to- 
data_o when data_state_gq contains fully encrypted 
data; otherwise, it drives a safe default value (e.g. 0) to 


data_o. Figure 7 shows how this solution impacts infor- 


mation flows from RndCnstKey. 

We disclosed this potential weakness and our pro- 
posed solution to the OpenTitan team. OpenTitan 
issued a patch to mitigate this leakage. The potential 
weakness is a low risk according to their threat model. 
However, the mitigation is simple, with minimal over- 
head. In addition to this disclosure to the OpenTitan 
team, we also submitted a new CWE to Mitre’s CWE 
database’ to cover the improper protection and leak- 
age of intermediate cryptographic state; this weakness 
was not previously covered by existing CWEs and is 
expected to appear in future CWE releases. 


www.computer.org/security 


developed a hardware patch that was accepted as a 
pull request into the OpenTitan repository. We also 


CWE database. m 


are 32 in total). data_state_q will only contain the submitted the findings as a hardware weakness to the 
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